The invention relates generally to the fields of personal computing and networking. Specifically, it relates to the new and evolving field of network computing, in which desktop computer users use a personal computer, possibly diskless, connected to a network such as a corporate intranet, the Internet, or to any network or Internet Service Provider (ISP) to gain access to applications which are then executed on the desktop computer. More specifically, the invention relates to server-based storage of software preferences (configuration data) and access permissions for software retrieved from a server and executing at the desktop computer.
The field of network computers is presently in its infancy. However, it is expected to evolve rapidly, especially in the corporate environment, for a number of reasons. The expectation is that as companies and possibly individual users reach hardware and software upgrade points, it will be more efficient and less expensive to move to this new field, rather than upgrade in the traditional way with disk equipped computers and locally stored and administered software applications. For example, in the corporate environment, a user can be connected to a corporate intranet, using, for example, the TCP/IP and HTTP protocols of the Internet, and download software applications as they are needed directly from a network server to the desktop computer. An application is executed on the desktop in the traditional manner by the user to perform useful work. An advantage of this configuration is that network computers are substantially less expensive than traditional disk equipped computers. It might also cost less to purchase the required number of software licenses for users, rather than purchase individual copies of software for each user. Certainly, the software administration problems that attend large numbers of corporate users will be substantially reduced. At the present time, each user of a disk equipped computer or workstation often is effectively his or her own system administrator, a role that often consumes excessive resources due to lack of expertise. It is expected to be a great advantage to eliminate this problem by effectively offloading the problem to a small number of server administration experts, rather than having many users struggle with the problems of software installation, upgrades and computer administration.
As mentioned above, this vision of the future of personal computing is presently in its infancy. As a result, there are presently many problems and deficiencies with existing systems.
Typically, in network computer systems, an administrator creates user profiles that are stored on a network server. The profiles may contain different types of information, such as user desktop preferences and user permissions for access to different software applications that might reside on the server. When a user logs onto the system, the user identifies him or herself to the server, the server locates the profile for the user and transmits it to the user computer where it is used to configure the computer and generate a desktop. The desktop might include a number of icons representing applications to which the user presumably has access. The profile likely also contains other attributes of the computer and desktop, such as for example, the background color of the desktop, or character fonts and point sizes used on the desktop, or data file search paths, etc. that are unique to the user. The profiles may be user modifiable or non-modifiable.
In an environment in which users can modify their own profiles, a modified profile is uploaded back to the server at log-off time, where it is stored for retrieval the next time the user logs-on. In some prior art systems, to the best of our knowledge, the users can generate on their desktops any configuration of application icons they wish, whether or not they exist on the server, and whether or not a user actually has access permission to an application on the server. The Lotus(copyright) Desktop (previously called Kona Desktop) system is an example of this type of operation. (xe2x80x9cLotusxe2x80x9d is a registered trademark of Lotus Development Corporation.) In other operation. In other systems, the server presents a list to the user of all applications that the server has, from which the user can pick. In this case, there is no guarantee that the user actually has access permission to an application that is selected from the list for inclusion on the desktop. The Sun Hot Java is an example of this type of system. (xe2x80x9cHotJavaxe2x80x9d is a trademark of Sun Microsystems, Inc.) In other words, the prior art systems do not correlate between systems do not correlate between what the user can configure for the set of desktop application icons and applications to which the user actually has access permission. In such a case, when the user clicks on an icon to execute an application, an error message may occur (such as an unauthorized access message) if access permission is not present, or in a worse case, the user""s computer may crash.
Another limitation with existing art is that a flat data structure is used to model users, user groups, terminals and groups of terminals. Modeled after a common scheme for managing user access to computer resources, known network computer implementations (e.g., Lotus Administration Facility for Desktops, Microsoft Windows NT Profiles and Policies, and Sun Hot Java Views) implement a flat xe2x80x9cgroupsxe2x80x9d structure on the server for managing software preferences (or attributes) in various contexts. A xe2x80x9ccontextxe2x80x9d, as used here, refers to an individual user, user group, terminal, or terminal group. Any grouping structure for managing software preferences on the server allows an administrator to define preference attributes for different groups of users as well as for individual users. However, flat systems are inflexible in many environments, especially in environments having large numbers of users. It is desirable to provide an administrative tool supporting the organization of preference information into a hierarchical structure.
Another limitation with existing systems is that they are limited in the ways that administrators and users have to perform user configuration of workstation desktops. For example, administrators are presently required to configure user preferences using configuration programs that are separate from, but associated with, a user application. It is desirable to allow vendors to provide only a single application. To require only an end user application from a vendor necessitates that the central management facility be able to execute the end user application in a context of a user or user group. The prior art does not allow this administrative flexibility of operation. In other words, in the prior art, to the best of our knowledge, an administrator does not have the ability to run a user application in the context of a user to set preferences for that user and application. Further, in the art, an administrator cannot run a user application to set preferences in the context of a group of users.
Still another limitation in the prior art known to the inventors is the manner in which the prior art partitions server permanent storage space to guarantee that a unique space is reserved for storing user preferences related to the different applications on the server. To the knowledge of the inventors, the problem of preventing collisions in the storage of preference information for different applications in object-oriented systems, in which an object can be queried for its fully qualified class name which uniquely identifies and differentiates it from other classes, is solved by having a first central authority assign a unique designation that applies to a vendor and by then having a second authority at the vendor assign a second designation relative to the first designation for each vendor application. For example, vendor A might be assigned the designation vendorA by the first authority and that designation is guaranteed to be unique within the architecture for which the first authority is acting. The second authority at vendor A then assigns the second designation for each of its applications within that architecture. For example, one of vendor A""s applications might be designated vendorA.App1; another might be designated vendorA.App2. The art maps the unique designation for each application in a system to a location in permanent storage of the system to guarantee that preference data for the different applications do not collide in storage. An application, when running, informs the network computer server of its unique storage location and it is the responsibility of the server to partition an area at the starting location according to a context (user, user group, terminal or terminal group) for storing preference information so as not to collide with preference information in a different context. Clearly, this manner of administering storage space is awkward and undesirable. It is desirable to devise a method to automatically generate unique storage locations for storing preference information for the afore mentioned object-oriented applications, without resorting to the requirement of having central authorities assign unique designations for the purpose of preventing collisions in the storage of preference information and without coding storage location information into an application.
Still another limitation in the art lies in the lack of any provision to migrate existing applications and hardware into the new environment of the centrally managed network computing world without requiring changes to the existing hardware and applications. Existing hardware, a terminal for example, in a networked environment, gets its configuration information at boot-up time from a file in a specific format located on a server. The terminal is programmed to know how to access its configuration file. The terminal uses a unique identifier to access the file from the server. The unique identifier is often the media access control (MAC) address of the terminal. However, in a new centrally managed environment involving protocols and API""s that are different from that to which the terminal is designed, the terminal cannot access preference information in the new environment, the terminal can only access its configuration file in the way for which it is designed. This is a serious problem, because there are many such existing devices in use. The inability to use them in new systems impedes substantially the incentives for users to migrate to the new systems.
Still another limitation in the prior art concerns the interface between an administrator and the configuration management system. When configuring software within an administration facility to configure preference information for various users and user groups, and terminals and terminal groups, the administration software launches in the context (user, user group, terminal or terminal group) set by the Administrator who is running the facility. When the Administrator changes the context that the application is running under, the application needs to be relaunched to load configuration information for the new context. The process of relaunching software each time a context is changed is time consuming and inconvenient for an administrator, especially in systems with many users. In such systems, it is expected that an administrator will change contexts many times while configuring an application.
The system described herein provides a common repository for configuration information for users and applets in a client-server environment. This is referred to as client profile management. The system allows users to roam, that is, to log-in from any computer in the system at any time and have it configured automatically at run time according to the preferences stored for the user at the server. The preferred embodiment is a Java (Java is a Trademark of Sun Microsystems, Inc.) based system and the client computers use a web browser interface arranged to execute Java applications. Thus, in the preferred embodiment, user applets and the desktop applet are assumed to be Java applets. However, it is not intended to limit the invention to a Java environment. Preferences for the locally stored applications might be stored locally in the traditional manner, while preferences for the server-based applets might be handled in the way described herein.
The invention solves the problem whereby a user is able to configure his or her desktop so as presumably to be able to access an application on the server when, in fact, the user does not have system permission to access the application. When the user logs onto the system, the user identifies him or herself to the server by means of a system identifier and a password. The server uses this information to dynamically built a list of applications to which the user has access permission. That list is transmitted to the user""s station. The application list is then used to build a portion of the desktop, preferably a desktop folder, of applications to which the user has access permission. Preferably, the folder is composed of a number of application icons each of which correspond to a different application and which may be selected by the user to launch the associated application. Associated with each application in the list are parameters necessary for the user to execute the associated application. For example, one such parameter might be the URL on the server used to invoke the application. Nothing prevents a user from modifying the desktop. For example, after the desktop is built, the user generally can add other application icons to the desktop, even though they would not be accessible to the user. A more common case might be where the user copies an application icon that is dynamically generated from the list from the generated folder to another part of the desktop and then logs off. When the user logs off, or otherwise saves his or her preferences for the desktop via any method the system might provide, the copied icon is saved to the server and becomes part of the preferences configured for the user. When the user later logs onto the system, the copied icon is reproduced on the desktop, not as part of the automatically generated list of accessible applications, but just as part of the individual preferences set by the user. Thus, the user can still wind up with applications configured on the desktop to which the user does not have access. A related feature of the invention prevents this occurrence from happening by also testing each application access preference set by the user against the application permissions present on the server. If a user has included an application object on the desktop to which he or she does not have access permission, then the object is automatically excluded from the desktop object that is built by the server at log on time.
In a preferred embodiment comprising a system with a network interconnecting a server and a plurality of user stations, the server stores a plurality of user applications for downloading to user stations and further stores access permissions for the applications for each user. When a user attempts to log onto the system from a user station, the server receives a user log-on identifier from the user. The server uses the identifier to build a list of applications for which the user has access permission. A desktop object is then downloaded to the user station to control the interface between the user and the user""s station. The server also downloads to the station a list of applications to which the user has access permission. The user station uses the list to build a folder containing only the applications from the list to which the user has access permission. The system further verifies that the user has access to applications that are represented by icons that the user may have added to his or her desktop at an earlier time. For each user desktop preference specified by the user at an earlier time that corresponds to a user application, the access permission for the user to the user application is checked from the list, and, if the application is not included on the list, the desktop object representing the application is removed from the desktop.